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NMG Note #16 , 
DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS 


During the last six months, we have been monitoring 
(although not continuosly) the performance of ur FTP-user and 
FTP-server programs. The purpose of this paper is to 1) discuss 
measurement criteria, 2) describe the measurement facilities, 

3) report the relevant measurement results, 4) discuss the 
significance of results and compare them with other measurement 
data, and 5) ask for suggestions on our measurement and 


summarizing procedures. 


l1. THE MEASUREMENT CRITERIA 

The FTP (Ref. "The File Transfer Protocol", by Abhay 
Bhushan, NWG/RFC 354, NIC 10596, ) may be considered a facility 
for data transfer between file systems. The relevant measurement 
parameters for a data transfer facility are: 
2) Tronaver rate (both peak and average, measured in bits per 
second) which determines the throughput of the data transfer 
facility. 
2) Respense tine or delay (measured in seconds) which determines 
the “interactibility’" of the facility. 
3) Processing cost (measured in dollars or cpu-seconcs per 
mesebit transferred) for transferring the Gata ketusan ine 
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cost of transferring data, tne other component being the 
communication cost (including lP processing costs) which we take 
as given. 

kL) Failure-to-connect rate - average time elapsed between 


failures to connect to the facility (measured in hours). 


Failures could ke jin the Host (processor and file system) 


hardware or software, or in the If!iPs and telephone lines. 
5) Availability - the percentage of time a given facility is 


available, or alternately the probability of RAITAR the facility 
available at a given time. 
6) Accuracy = measured by the probability of error in 
transferring bits, Bytes, blocks, or files. 
Il. THE MEASUREMENT FACILITIES 
The MIT-CMS survey program (ref. "A Report on the Survey 
Project" by Abhay Bhushan, NUIG/RFC £30, NIC 17375) measures the 
response-time, failure-~to-connect rate, and availability of the 
Host-logger facility (on socket 1). Our preliminary experiments 
have indicated that the corresponding measurement results for the 
PTP are very close to that for the logger (at least they are the 
same order-of-magnitude). As the use of FTF and the ARPANET is 
increasing rapidly, most Hosts have tneir logger and FTP 
operational whenever their Host and NCF (Network Control Program) 
are functioning. The response time for obtaining the use of FTP 


service is very close to that for cbtaining the use of the logger 
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service as both involve the use of the ICP (Initial Connection 
Protocol). | 

Preliminary results from the Survey Project indicate that 
the average response time in recent months has been about 2.7 
seconds. The average availability has been about €5% with the 
failure-to-connect rate being about once every 10 hours. Table | 
shows summary results for the time period August 26 through 
August 31, 1973, for three Hosts with TENEX operating systems 
(SRI-ARC (NIC), BBN-TENEXA, and USC=1S1). 

The reader is cautioned that the data below reflects the 
Host performance as seen by the MIT-DMS survey program which 
surveys the Hosts only once every twenty minutes. Consequently, 
the actual host performance may be somewhat different. Also, we 
cannot distinguish between IMP, telephone lines, and Host 
failures and tne response time of a host is affected by its 
distance (number of IMP hops) from the MIT IMP (INP 6). 


In the data shown in Tabie Il, each sucess or fail response 


is considered to have a duration of 20 minutes, so Hosts are 
given the benefit of the doubt for the time we are not surveying. 
In addition, the respense time has been averaged only for the 
successful logger available responses. The logger is considered 
available It the SURVEY program can establish a full-duplex 


connection within 20 seconds. The Host is considered available 


when It Is not in the "CEAD" state (states in which logger Is not 


up but the Host is available are logger not responding and logger 
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rejecting). 


TABLE | 
RESPONSE TINE, AVAILABILITY, AND FAILURE PATE FQR SELECTED HOSTS 
~~ (Based on SURVEY data for 8/25/73 through 8/31/73) 
PARARETER NIC BBA IS] 

Average Response-time (sec. ) 2.7 2.4 3.0 

Host Availability 93% 85% 87% 

Logger Availability 91% 79% 383% 

. Failure-to-connect rate l 

S Sor Host (hours) l 18.2 9.4 18.1 


Failure-to-connect rate 


for logger (hours) 16.0 6.9 10.0 


The details on the above measurements will be reported ina 
forth-coming paper. This paper will focus on the remaining 
parameters of transmission rate, processing costs and accuracy, 
as measured by the MIT-DHS File Transfer Measurement facility. 

The FTP measurement facility exists in the MIT-DMNS CALICO 
subsystem. Each time the MIT-DMS FTP-user or FTP-server program 
in the CALICO subsystem is used to transfer files (and data) via 
the ARPANET, it records in a local disk file the following 
transfer parameters: the remote Host involved, the date and time 
the transfer is initiated, the total number of bits transferreed, 
the real time taken (in seconds) for the transfer, the CPU time 
(in micro-seconds) used by the program, whether the program is 


the server or user, and the FTP parameter settings for byte size 
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(BYTE), representation type (TYPE), transfer mode (HODE}, and the 
file structure (STRU). Programs exist in CALICO to display and 
summarize this data. 

It should be noted that no measurements are recorded when 
the non-CALICO FTP-user and FTP-server programs are used for 
transferring ites; Therefore e cheute be pointed out that the 
measurement represents a small subset of our total FTP-usage. 
The CALICO FTP-server was operated only till May 1973, when we 
switched te the non-CALICO FTP-server.. (The switch was made 
because CALICO still undergoing development is somewhat less 
reliable. As CALICO stabilizes we may again operate the CALICO 
server and continue measuring data transfer.) In addition many 
users prefer to use the simpler (involving fewer system 
resources) stand-alone FTP-user program. The measurement does 
include the data transferred when FTP is used indirectly by such 
commands as "copy", "print", "listf", and "mail.file™ in the 


CALICO NETWRK subsystem. 


Ill. THE MEASUREMENT RESULTS 

The measurement facility has been operational (though not 
continuously) since 25 February 1973. It has recorded the 
transfer of 304 files consisting of 57.6 million bits. Over S0% 
of the bits transferred (but only 75% of the files)used the more 
efficient Image-36 stream mode (TYPE I, BYTE 36, MODE S$) of 


transfer. The remainder of the files were transferred using the 
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ASCII-8 stream moce (TYFE A, BYTE 8, MODE S). It should be noted 
that even though block mode was available, it was never used by 
our users (primarily because many FTP-servers do not implement 
it, and it is less efficient to use). All the files had a 


sequential nen-recora file structure (STRU F). A summary of the 


measurement results is shown in Table Il. 
ABLE IlI 
UMMARY OF FTP MEASUREMENT RESULTS 

Subset of data # Files # bits Av. ‘ile Speed  CPU-use 

Mbits Kbits Kbps sec/Mb 
Total 304 57.6 185 7.56 4 
Image 30 mode 223 53.06 240 9.35 5 
ASC11-8 mode 81 4.0 49 2.09 — 19 
Server sending 62 3.3 61 7.50 2 
Server receiving 110 19.8 180 . 7.44 1 
User receiving 83 22.8 276 7.92 6 
User sending 49 11.1 225 7.09 4 


The entire display of the measurement data and the summaries 


shown in Table II are generated by the "PFTPST" (Print FTP 
STatistics) progran in the CALICO subsystem. A sample of the 
data displayed is shown in Table IIl. The BPS (bits per second) 
and the M/B (CPU microseconds per bit or CPU seconds per Megabit) 
information is saieta by the disolaying program. The largest 
file transferred was 5.03 Mbits, a "STOR" Ly the FTP-user to MIT- 


Al. The transfer took 10 minutes of real time for a transfer 
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rate of a little over 10 Kbps. The highest data transfer rate 


recorded was 27.8 Kbps, a "RETR" from B3N-TENEXA to MIT-DMS STP- 


server. The length of the file in the above case was 28 


Kbits. 


Needless to say that both of the above transfers used the more 


efficient !mage-35 mode for transfer. The smallest file 
smallest transmission rate recordec was an 80 bit "MLFL" 
ML (using ASCII-8) which took 7 seconds real time for 11 


transfer rete. 


TABLE FH 
“SANPLE DISPLAY OF ETP MEASUREMENT DA 


-#- ---HOST--- COMM --DATE-- --TIME-- --BITS-- -BPS- M/B 


——Ė 


2 sri-arc STOR 73/08/59 18:19:49 121392 13395 21 
192 mit-m] STGR 73/08/15 15:06:30 sög 633C 8 
1390 mit-n] RETR 73/08/15 15:91:14 59688 10137 2 
198 nit-mn] STOR 73/68/15 15:92:33 255456 8808 7 
188 mit-21 RETR 73/08/15 15:03:58 253048 8651 12 
134 mit-ai STOR 73/08/15 15:13:17 280720 1898 25 
134 mit-ai RETR 73/08/15 15:18:49 258045 9557 14 
13} mit-ai STOR 73/98/15 15:19:42 258C43 6974 7 

2 sri-arc RETH 73/08/15 15:31:20 7236 3618 22 

2 sri-arc STOR 73/08/15 15:32:55 49428 8233 31 

2 sri-arc RETR 73/08/15 15:24:5€ bG428 3530 15 

2 sri-arc STOR 73/08/15 15:32:09 49426 7061 a 

2 sriverc: . STOR 73/08/20 15:18:26 35460 2364 S 

2 sri-arc RETR 73/08/20 16:62:29 £8832 h26 153 

2 sri-arc RETR 73/06/22 12:46:10 16512 IGE 247 

2 siti-arc RETR 73/08/23 16:29:37 320 64 369 

2 sri-arc RETR 73/06/24 12:25:38 9952 262 254 

2 srji-are RET: 73/08/24 12:27:76 9992? L54 25¢ 
198 mit-%l STOR 73/08/29 10:40:58 766924 7538 7 
198 mit-ml STOR 73/23/29 19:44:99 166572 5552 7 
193 mit-01 STCR 73/98/29 1:54:32 15657? 7932 7 
198 mitcml STOR 73/08/29 13:45:18 155040 32156 7 

69 bbhn-tenema MLEL 73/08/29 22:30:55 56CG 1866 51 
6S bbn-tenexa MLEL 73/98/29 22:32:42 5600 2ə00 59 
SG uszc-isi MLFL 73/02/29 22:35:55 5600 1409 Ft 
69 bbn-tenexa MLFL 73/08/29 22:36:15 5¢60 2800 4&8 


and the 
to MIT- 
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69 bbn-tenexa MLEL 73/08/29 22:36:54 l 5600 28500 UG A 8 U 


It should be pointed out that recent measurement data for 
A3ct:-8 transfer includes rateteval of "HIG Journal’ documents 
("<xjournalèxxxx<.nls;xnls" files) from SRI-ARC. SRI-ARC 
converts these "xnls" files from NLS to sequential form cn the 
"fly" and this takes considerable time giving a low transfer rate 


for these transfers. 


by 


In transferring files we found the ARPANET and the FT? to be 
quite reliable. On numerous occasions we-transferred complete 
listing of our operating system (about 6 million bits), 
reassembled it and ran it with ne problem. No cata lossage 
probloms nave been reported te us as yet. 


SIGNIFICANCE OF MEASUREN 


First of a1] let me state my complete agreement with Barry 
Wessler (Ref. "REvelaticns in Network Host Measurements" NWG/RFC 
557, Hie 18457) that the measurement results sivuld be taken in 


the spirit: here is z place te make the Network better" 


rather 


than: "Look, isn't the !Hatwork terrible. Ne take these 


measurements in the same soirit and have found the measuremencz 
effort to be guite fruitful. in several instances, with the zid 
of our measurenent facilities, we have been able to improve the 
performance of our Network programs by an order-of-magnitude 


(just as Son Allen at BBE improved Greg Hicks' RJS program). 


Our measurement reselts ure in close agreement with the BRNE 
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FTP measurements (8.2 cpa seconds/ib for 3-bit byes and 2 CPU 
seconds/idik for 36-bit byte transfers). We also find the 36-bit 
byte transfer to be an order-of-msgnituce mere efficient than 3- 
bit byte transfer. The precessing cost (assuming $6.00 per CPU 
minute) for transferring a “egubit of information comes to about 
$1.90 for ASCII-8 mode as cempared to only $60.3) for Image~-36 
mo.ie. The difference in transfer rate is equally astounding 
being 9.4 Kbps ar Image-36 as compared to only 2 kbps for ASCIli- 
8. 

It is therefore recommended that Image-36 mede be used as 
mack as possible te transfer data between PDF-19%s fof which there 
are many an the ARPANET). lt is strongly urgec that protocols 
and programs allow (and use) the Inage-36 mcde for all data 
transfers including maflirng files CMLFL), listing directories 
(LIST, NLST), ang sending/retrieving HIC Journal documents. Many 
of the MIT-DHS user programs such as "COPY" and "FTP" take 
advantage of the fact that tne remote Host is a PDP-10 (there is 
a table of PGP-10's in "COFRY") and use the more efficient Image- 
36 mode. Such a procedure is hizhly RoceneHdec:. 

"The effective IMP-1t!P data transfer rate is about 37.5 Kopps 
over the 59 Kbps telephone line (Ref. McQuillan Vvelbn M., 
"Throughpet in the ARPA Natwerk scene ySis and Measurement," BBN 
Report 2491], EIC 14188, January 1972). The Host-to-lios: date 
transfer measurenent performed by REN (above reference, p. 28) 


have irdicated a transfer rate cf 30-35 kbps SRN-to-3P! (2 IMP 
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hops) and 12-16 Kbps BBN-tso-SR! (5 hops) using single link. As 
FTF transfers cata via a sirgle Jink, a maximum transfer rate 
between 12 and 35 Kbps (depending on number oy P hops) can be 
expected if that file transfer is the only activity gcing on. In 
this light our maximum transfe- rate of 27 Kbps to BRN (2 hops) 
is probably the most one can expect out cf any pregran. The 
average transfer rate of 9.4 Kbps (for Imazge-36) transfer also 
appears reasonaple in view of the fact that during many of the 
transfers other network activity is also going on, ana that many 
of the transfers are performed when the respective computer 
systems are quite heavily loaded. Our measurement data dces 
reveal taai transfer rate is appreciably higher curing the times 
a computer is; likely to be lightly jtoadead. 

The above dees not mean that improvements are not possible 
or not requirad in the state of the ARPANET data transfer. Our 
measurement cata has revealed areas in whieh improvements can be 
and should be nace. For example, the transfer cf data to other 
HIT Hosts (2 IMP hops) and back to ecurselves should be faster 
than what we currently achieve (transfer to BEN is faster!). The 
nrobeble reason for the above discrepency is that our allocation 
(Host-Host protocol) is very small (2944 bits) as compared to 
that provided by BBN (17724 bits). This means that to transfer 
data our Ketwork Control Program (HCP) has to wait for an 
allocation many more times while communicating to an ITS systen 


than to a TENEX system. Large allocations are always desivabdle 
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but even more so white transferring files. NCP designers can 
(and should) modify NCP's to allow large allocates (larger NCP 
buffers): for file transfer even “at the expense of smaller 
allocates for other typez of connections (such as a terminal 
connected to a computer system) which do not require or ase the 
larger allocation. In addition, Sie allocate should be sent as 
soon as dats is read ky the receiving program (the NCP should not 
wait for the allocation to become zero before sending the new 
allocate). 

We also observed that small files-.are transferred at a 
significantly lower transfer rate than large files but beyond a 
file size cf 40 Kbits, the file size makes little difference in 
transfer rate cr processing cost per bit transferred. The figure 
of 40 Kbits is probably related to the size of sending and 
receiving buffers used by the programs. In general, for most 
practical values of buffer size, the larger the buffer size and 
allocations, the faster and more efficiant will be the transfer. 
Unfortunately, large NCP buffers are not easily available in many 
systems and come at a premium. The infermation on average file 
size (240 Kbits for Image and i9 Kbits for ASCII files) may be 


helpful in optimum ellocation cf buffer space. 


V. REQUEST FOR COMMEN 


It Is hoped <hat the above measurement results and our FTP 


and SURVEY measurement facilities witl help ARPANET users plan 
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their modes of Network usage and help Network programmers in 
making the Netvork better. This RFC is indeed a Request Fer 
Comments and your suggestions on the way we collect, store, and 
display measurement data witl be greatly appreciated. We can 
break the measurement data by Hosts and will be happy to provide 
the information if it is considered desirable. Please let me 
knew what other parameters we should record or display. Yeu may 
communicate with me via the ARPANET (AKER at MIT-DMS (Host 72), 


NIC Ident AKB), via telephone (€17-2353-1428 or 14493, or US nail 


(Ra. 208, 545 Tech Square, Cambridge, Mass 02139). 


